home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19941031-19941221 / 000205_news@columbia.edu_Sun Nov 20 17:52:33 1994.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA17665
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Mon, 21 Nov 1994 05:40:32 -0500
  3. Received: by apakabar.cc.columbia.edu id AA07192
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 21 Nov 1994 05:40:31 -0500
  5. Path: news.columbia.edu!news.media.mit.edu!bloom-beacon.mit.edu!news.kei.com!hookup!relay.tor.hookup.net!newsadm
  6. From: bangus@hookup.net (Brian F. Angus)
  7. Newsgroups: comp.protocols.kermit.misc,alt.winsock
  8. Subject: Re: winsock/pkt dvr hack possible?
  9. Date: Sun, 20 Nov 94 22:52:33 est
  10. Organization: hookup.net
  11. Lines: 31
  12. Message-Id: <3ap5jm$km8@relay.tor.hookup.net>
  13. References: <3a67j8$j39@Mercury.mcs.com> <Pine.SUN.3.91.941118031532.9000A-100000@soleil> <3aiudg$pil@apakabar.cc.columbia.edu> <3anvci$dut@relay.tor.hook <1994Nov20.105834.33349@cc.usu.edu>
  14. Nntp-Posting-Host: bangus.tor.hookup.net
  15. Mime-Version: 1.0
  16. X-Newsreader: WinVN 0.93.0
  17. Xref: news.columbia.edu comp.protocols.kermit.misc:1149 alt.winsock:22495
  18. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  19.  
  20. In article <1994Nov20.105834.33349@cc.usu.edu>, jrd@cc.usu.edu says...
  21. >
  22. >        Jeff is correct. The top of a sockets API is a TCP stream channel of
  23. >bytes, not packets. "It could be done..." means creating a second TCP/IP
  24. >stack feeding from the streams channel and packaging it into TCP/IP over
  25. >Ethernet frames to be passed to the application. Not very desirable, nor 
  26. >realistic.
  27. >        Joe D.  
  28.  
  29.  
  30. Many interesting projects arise from rather pointless objectives, and in
  31. this case, I believe we have the perfect example of a truly pointless
  32. objective.  But, to continue this one step further (yes I know this isn't
  33. really attempting to solve the original problem), instead of trying to tie
  34. into the Winsock API, would it be feasible or even possible tie a DOS packet
  35. driver into the Windows based NDIS3 drivers (I believe MicroSoft's PPP
  36. driver is only supplied as an NDIS3 Windows based driver).  It seems to me
  37. there would still be the problem of multiplexing multiple IP stacks (very
  38. undesireable).
  39.  
  40. Brian A.
  41.  
  42. P.S.  Just trying to promote some more interesting and irrelevant discussion.
  43.  
  44. -- 
  45.  _---_   -------------------------------------------------------------------
  46.  /o o\   Brian Angus                        Unsupported hack supporter - DEC
  47. (  |  )  bangus@trooa.enet.dec.com          
  48.  \_=_/   bangus@hookup.net                  The one with the most shims wins
  49.          -------------------------------------------------------------------
  50.